Aspect oriented programming (AOP) is a software development paradigm for providing application code which accurately reflects an application design. In this way AOP provides for simplified application development and maintenance. AOP achieves this by recognising how aspects of an application, known as “concerns”, can cut across the entire application. For example, concerns such as security, tracing and logging can be fundamental to application design and can affect most or all of an application. AOP allows for such concerns to be extracted and designed independently of other concerns, whilst being implemented in a way which potentially affects an entire application as appropriate. Concrete means for achieving these objectives include join points, pointcut expressions and advice. These means and associated techniques are considered in detail in existing AOP literature such as the “AspectJ Programming Guide” (available at eclipse.org/aspectj/doc/progguide/index.html) and are further considered below (AspectJ is a registered trademark of Palo Alto Research Center Incorporated).
One technology for employing AOP in software development is known as AspectJ. AspectJ provides for the compilation of aspect oriented applications in the Java language (Java is a registered trademark of Sun Microsystems). The conventions and program fragments used herein generally relate to AspectJ, although it will be apparent to those skilled in the art that the concepts and techniques are equally applicable to the generic field of AOP and any particular aspect oriented software development implementation.
A join point in a software application is a well-defined point in a program flow. For example, the action of an object receiving a method call is a clearly-definable point in a program flow, and is known as a method call join point. Other examples of join points include the execution of a method body, a reference to a field or the execution of an exception handler. Join points can be identified and used in an aspect oriented application through a definition of an expression known as a pointcut. For example, a pointcut defined as:pointcut radiusUpdate( ):call(void Circle.setRadius(long))relates to each join point that is a call to a method having the signature “Circle.setRadius(long)”. Once defined, pointcuts are used to provide code, known as advice, which can be executed at runtime when a join point is reached.
Although join points defined by pointcut expressions are all logically determined at runtime, it is sometimes possible to determine at compile time those join points that will be matched by a pointcut expression when the application is later executed. For example, with a pointcut expression which matches calls to a method with a certain name the matches can be fully determined at compile time because the names of methods in the application are known. Such pointcut expressions are known as static pointcut expressions. However, sometimes the matches cannot be fully determined at compile time. For example, a pointcut expression might match calls to a method which is passed an object parameter that is an instance of a particular class. In the general case it is not possible to fully determine the matches at compile time because the runtime instance of an object cannot always be inferred from the source code. Pointcut expressions such as this are referred to as dynamic pointcut expressions.
In order to effectively develop aspect-oriented applications, good tooling support is required. This can help developers by indicating where parts of an application are going to be affected by advice at runtime. An example of such tooling is AJDT (AspectJ Development Tools). For static pointcut expressions the tooling can show the exact matches within source code, but this is not possible for dynamic pointcut expressions. Currently AJDT indicates all potential matches of a dynamic pointcut expression with a particular marker icon to indicate that there is an additional runtime test to determine the exact matches. However, this cannot help developers understand the case where the pointcut is not matching the required places at runtime.
It would therefore be advantageous to provide a mechanism for identifying where a dynamic pointcut expression is satisfied and, in particular, where the dynamic pointcut expression could be satisfied but is not satisfied in application code. This is an established need, as is considered, for example, in the paper written by Katharina Mehner and Awais Rashid entitled “Towards a Standard Interface for Runtime Inspection in AOP Environments” available on the world wide web at www.comp.lancs.ac.uk/computing/aose/papers/FASOP_AOSDTOOLSWS2002.pdf).